Мы пытаемся подключить клиент javamail (1.6) к нашему почтовому ящику office365, размещенному в office365, с использованием аутентификации OAUTH2.

Что бы мы ни делали, мы продолжаем получать ошибку A1 NO AUTHENTICATE.

Мы зарегистрировали наше приложение в

Разрешение API

Мы следовали всем инструкциям, изложенным в

https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth

Включая запуск команд powershell для создания принципала с использованием идентификатора приложения и идентификатора объекта, и мы предоставили приложению полный доступ к почтовому ящику, к которому мы хотим получить доступ.

Для аутентификации мы делаем HTTP POST следующим образом, который генерирует токен доступа.

Это поток учетных данных клиента с общим секретом, как описано здесь. https://learn .microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow

https://login.microsoftonline.com/{наш идентификатор клиента}/oauth2/v2.0/ жетон с

Наша конфигурация javamail

Затем в нашем java-коде мы подключаем хранилище с токеном доступа, полученным из вышеуказанного HTTP POST

Мы также попробовали этот скрипт powershell, который возвращает ту же ошибку.

https://github.com/DanijelkMSFT/ThisandThat/blob/main/Get-IMAPAccessToken.ps1

Я не считаю, что проблема специфична для JavaMail.

Чрезвычайно сложно определить, имеет ли токен доступа правильные права или есть что-то еще, что мешает аутентификации.

Что еще мы можем попробовать?

Обновление 1

Если мы используем скрипт powershell

https://github.com/DanijelkMSFT/ThisandThat/blob/main/Get-IMAPAccessToken.ps1

Передавая только идентификатор клиента и redirectUri, сценарий запрашивает у меня одобрение, и он преуспевает

Но если мы используем clientsecret авторизация не работает

Обновление 2

Я могу успешно использовать javamail с токеном доступа, сгенерированным сценарием powershell.

Очевидно, что токен, созданный с помощью clientsecret, не имеет достаточных прав для доступа к IMAP или почтовому ящику.

Я начинаю задаваться вопросом, не работают ли запросы токенов с использованием секрета клиента, потому что в нашей Azure Active Directory включены «параметры безопасности по умолчанию».

Возможно, применяется MFA, поэтому любые неинтерактивные запросы блокируются.

Обновление 3

https://jwt.ms позволяет декодировать токены доступа

Токен, созданный только с идентификатором клиента (поток предоставления кода), сильно отличается от токена, созданного с помощью client_secret (поток учетных данных клиента).

В токене из «интерактивного предоставления кода» есть атрибут под названием «scp» Set of Scopes, в котором перечислены области действия независимо от того, что у меня есть в разрешении API моего клиентского приложения ????

Второй токен из потока учетных данных клиента имеет атрибут «роли», но не имеет областей действия.

РАЗРЕШЕНО!

Глядя на токен доступа, мы заметили, что субъект потока учетных данных клиента (sub) был идентификатором, который мы не настроили.

Вот в чем загвоздка: при создании субъекта-службы с помощью powershell в онлайн-обменнике в качестве идентификатора службы вы должны использовать идентификатор объекта корпоративного приложения.

New-ServicePrincipal -AppId {clientid} -ServiceId {идентификатор объекта корпоративного приложения -Organization {tenantid}

При создании регистрации приложения в Azure AD вы также создаете корпоративное приложение.

Идентификатор объекта приложения отличается от идентификатора объекта корпоративного приложения.

Поток учетных данных клиента использует идентификатор объекта корпоративного приложения в качестве пользователя, запрашивающего авторизацию.

То же самое для предоставления доступа к почтовому ящику с помощью powershell

Add-MailboxPermission -Identity {email} -User -ServiceId {идентификатор объекта корпоративного приложения -AccessRights FullAccess

Жаль, что процесс аутентификации такой громоздкий

Мои два цента по этому поводу: если вы все еще сталкиваетесь с ошибкой аутентификации из-за того, что javamail пытается подключиться к почтовому ящику и читать электронные письма, прежде всего убедитесь, что установка приложения в активном каталоге azure имеет следующие разрешения.

IMAP.AccessAsApp

Почта.Чтение

Mail.Send (для отправки)

Во-вторых, создайте субъект-службу с идентификатором корпоративного приложения, как указано в исходном сообщении. После этого проверьте здесь, есть ли у созданного вами токена все роли, которые вы назначили.

Даже если вы назначили необходимые роли и можете подключиться к почтовому ящику через powershell, вы все равно можете получить AUTHENTICATE failed от javamail, потому что вы можете неправильно использовать это свойство (mail.imap.auth.mechanisms), замените mail.imap с помощью mail.imaps, и это должно решить проблему.

Удачи !!